Following Joey’s lead, here’s some DWN-style comments on some of the stuff I’ve been involved in or heard of over the past week… A future for m68k has been planned on the release list, after being officially dropped as a release architecture in September. The conclusion of the discussion seems to be that we’ll move the existing m68k binaries from etch into a new “testing-m68k” suite that will be primarily managed by m68k porters Wouter Verhelst and Michael Schmitz, and aim to track the real testing as closely as can be managed. In addition the m68k will aim to make installable snapshots from this, with the aim of getting something as close as possible to the etch release on other architectures. A new trademark policy for Debian is finally in development, inspired by the Mozilla folks rightly pointing out that, contrary to what we recommend for Firefox, our own logos aren’t DFSG-free. Branden Robinson has started a wiki page to develop the policy. The current proposal is to retain two trademark policies – an open use policy for the swirl logo, that can be used by anyone to refer to Debian, with the logo released under an MIT-style copyright license, and left as an unregistered trademark; and an official use license for the bottle-and-swirl logo, with the logo being a registered trademark, but still licensed under a DFSG-free copyright license. The hope is that we can come up with at least one example, and hopefully more, of how to have an effective trademark without getting in the way of people who want to build on your work down the line. Keynote address at OpenFest. Though obviously too modest to blog about this himself, Branden Robinson is currently off in Bulgaria, headlining the fourth annual OpenFest, speaking on the topics of Debian Democracy and the Debian Package Management System. New Policy Team. After a few days of controversy following the withdrawal of the policy team delegation, a new policy team has formed consisting of Manoj Srivastava, Russ Allbery, Junichi Uekawa, Andreas Barth and Margarita Manterola. Point release of sarge, 3.1r4. A minor update to Debian stable was released on the 28th October, incorporating a number of previously released security updates. Updated sarge CD images have not been prepared at this time and may not be created until 3.1r5 is released, which is expected in another two months, or simultaneously with the etch release. Debian miniconf at linux.conf.au 2007. While it may technically not be supposed to be announced yet, there’s now a website for the the Debian miniconf at linux.conf.au 2007, to be held in Sydney on January 15th and 16th (with the rest of the conference continuing until the 20th). This year derived distributions are being explicitly encouraged to participate, so competition is likely to be high, and it’s probably a good idea to get your talk ideas sorted out pretty quickly if you want them to be considered!

Catching up on blogs, emails and Debian mailing lists I see that nothing really important has happened while I was off-line: the dunc-tank caboodle escalated and died down when the majority voted that it was not worth the commotion, some people got upset at some other people and decided stop working on Debian because of that, Mozilla went even more bonkers about its trademarks. The dunk-tank scandal ended just like I thought it would. As one could imply from my eternal unstable concept, I do not see making releases as a the main thing that Debian contributes to the society - it is more about the integration and cross-empowerment of all the packages that Debian has. In that context, making a release is a not the most important job in Debian, but it need to be done from time to time. Release management combines technical and social challenges - there is not much of novelty in it (I imagine). So, from this perspective, there is nothing bad in money being paid to do this mundane and hard work, if we really, really need to release in a specific time frame (IMHO the only reason to release Debian in 2006, as opposed to 2008, is the Lars tattoo bet). If we return to “release when its ready” paradigm and aim for about one release every 2-3 years (and I see nothing really wrong with that) then paying release manager will not be needed. Money is about getting things done on a schedule. It does not make things good (or bad). It does not make thing important (or not). It make things go by the schedule (unless you pay by the hour). It is the obvious solution to releasing Debian in December. Now two questions need to be answered - will it work? and do we really want to release in December? The second thing - in any group of 1000 people anyone can easily find a lot of people that he would not love/not respect/disagree with/disregard/hate and be unable to work with. It is no reason to stop working on Debian, unless one does it only to be universally loved. It is inevitable that we will need to learn to do what we like to do without paying attention to the irritations. And about the trademarks - in Debconf 5 in Helsinki I was giving a talk at the Debian Day, just after I helped to win the first big fight against software patents in EU, and Branden (who was GPL at the time) asked me what do I think Debian should do about its trademarks. Both then and now I strongly think that trademarks and any other litigation inducing concepts (except enforcement of GPL) have no place whatsoever in free software. I think Debian should lead the way and give up the “Debian” trademark. And Mozilla should follow the lead. So what if there is a pron site “Debian chicks”? You will not solve that with litigation anyway (at least not in a year or two) and why should we really care? So what if some one make a distro and calls it SuperDebian? If someone will really think that it is related to Debian but better (especially despite warnings to the contrary), then that someone will really deserve to get the trojan planted in that distro. And again, against a well prepared criminal, litigation will not help much. So, did I miss anything?

I was in a multiple-car accident yesterday. I've been having to tell this story a fair amount in person and on IRC, so I thought I'd blog about it. Short version: it was a fender-bender. I'm doing fine, nobody was hurt, Michelle wasn't in the car, and 75% of the cars involved were driven away from the scene — including mine, by me. Want the long version? Well, I'm gonna tell it anyway. I had just pulled to a stop at a traffic light, heading northbound on Keystone Avenue where it intersects 106th Street, in Hamilton County. The line of cars at the light was pretty long, and people love to try hauling ass on the stretch between 96th Street and 106th. Apparently the person behind me was one of them. The line of cars stopped in the left lane (where I was) at the light was pretty long, and much shorter in the right — the cars over there were still moving at a good clip. I looked in my rearview mirror, thinking "if someone's trying to match pace with the cars in the right-hand lane, they're gonna need to brake pretty hard to stop." It was about 1815, so it was starting to get dark. A pair of headlights approach. Fast. Oh boy. I don't stop right up on people's tails, so if I'm hit, hopefully I won't go into the car ahead. I look forward again. Yeah, there's some room here. Screech. I didn't tense up; I felt a strange sense of calm and curiosity, as I'd never been in a car accident before. I bought my car, a Volkswagen Golf, in part because of its fairly good safety ratings. It has lots of air bags, and I always use a seat belt. Plus, in this instance I figured I wouldn't get hit a high speed. "Strange Deja Vu" by Dream Theater, from the Scenes from a Memory CD, was playing. Normally I listen to All Things Considered while commuting home, but I was annoyed because when I got in the car, I heard Nina Totenberg signing off a report, which means I'd just missed some Supreme Court coverage. Damn. Anyway. BONK. I got hit. Ouch. My teeth had chomped together too hard. Maybe they should install rubber mouthpieces in the doors of cars so you can grab them right before a crash. You know, car crashes never sound like the stock sound effects that have been around for about 50 years. I guess that's because they build cars to crumple these days instead of act like steel shrapnel bombs. Damn that Ralph Nader. My wreck doesn't sound cool and stuff. And I get to walk away, well, get back in the car and drive away, instead of my wife collecting on my life insurance policy. But I digress again. A middle-aged woman in a Honda Civic skidded into me, and knocked me into the Buick Park Avenue ahead of me, which in turn tapped the minivan ahead of him. I blinked a bit and tried to reorient myself, and then turned off the CD player. We all got out of our cars. The woman in back was very distressed, and immediately and repeatedly said the thing your insurance card tells you never to say after an accident. Oh well. Being a middle-aged woman, she'd probably have to wreck a school bus full of children — twice — before her premium would go up. Mine, on the other hand — we'll see. Called 911. Reported the incident. Tried to call my wife, but she decided not to answer. I later found out she was gabbing it up with my mom. Isn't it nice when your wife gets along with your mother? I COULD BE BLEEDING OUT ON THE COLD ASPHALT, BUT YOU TWO JUST KEEP ON TALKING. Michelle and I have the same model of cell phone, and we have call waiting with caller ID, so I know she knew it was me. Anyway, I try a couple of times, then give up and leave voice mail. Turns out the guy in front, in the minivan, was a Deputy Prosecutor for Hamilton County. He said something about being experienced in car wrecks, but I don't clearly remember it. Anyway, perhaps in part because he decided he was only "tapped" and didn't need to file an insurance claim, and perhaps in part out of professional courtesy, when the cops showed up, they let him go very quickly, so I didn't get any of his information. Everybody was fine, polite, and decent about the whole thing. The couple ahead of me, whom I got knocked into, didn't have their insurance info on them (or maybe this is a euphemism for "don't have insurance"). But, except for the deputy prosecutor guy, who was outta there, we all traded names, addresses, and phone numbers. I hope the Debian Project doesn't mind that I used my Debian Project Leader business cards for this purpose. These people (and the Carmel Police Department) now have my GPG key fingerprint. Uh oh. Anyway, that's about it. Appointment tomorrow with the insurance agent, to get help filling out INDIANA OPERATOR'S VEHICLE CRASH REPORT, State Form 38656 (R6/7-91) Stock 301 Effective 1-92, which has to be filed with the Indiana State Police within ten business days, or my driver's license will be suspended. Aww, yeah. Gotta move fast, because on Friday I leave for Mérida, Spain, to attend the 2nd Annual Open Source World Conference in Extremadura. Also have an appointment with the claims adjustor tomorrow. Then I'm hoping to just leave my car at the dealership so they can work on it over the week when I'm gone. My wife and my mom, those talkative two from a couple of paragraphs ago, will be coming along with me. My mom's got a jones to visit Spain, and I've had a jones to take my wife to Europe. We'll have a couple of extra days to see what Spain is like — I'll be there from 22 October to 28 October. I hope one day to visit Barcelona and hang out with some proper anarcho-syndicalists.

The Constitution of the Debian Project specifies a decision making process known as "delegation", which the Debian Project Leader can use to spread decision-making authority throughout the Project. Historically, this power has been underused (including by myself), particularly in areas of infrastructural administration. This turns out not to be due to any lack of motivation or desire to do so on the part of past (or present) Project Leaders. I have learned that part of the problem with delegation is that the Constitution's concept of it is poorly understood by some of our developers, particularly those who are not native English speakers and for whom the dry legal language in the document is heavy going. Here, then, is my attempt to put delegation in a nutshell:

1. Any authority not otherwise assigned by the Constitution (e.g., to the individual Developer, Technical Committee or the Secretary) can be exercised by the Project Leader, either directly or through delegates.
   (5.1.1, 5.1.2, 5.1.3, 5.1.4)
2. In the case of "approving or expelling Developers or designating people as Developers who do not maintain packages", this authority must be exercised by a delegate, and not by the Project Leader directly.
   (8.1.2)
3. The Constitution suggests that there may be other powers which the DPL may not directly wield, and which he or she must delegate instead, but apart from the above, none are enumerated in the Constitution.
   (8.1.2)
4. The DPL can make two types of delegations: a particular decision, or an ongoing area of responsibility.
   (5.1.1)
5. If the DPL delegates a particular decision, he or she cannot retake responsibility for the decision personally, but can re-delegate it to someone else.^[1]
   (5.1.1, 8.2)
6. If the DPL delegates an ongoing area of responsibility, he or she can withdraw that delegation.
   (5.1.1)
7. The DPL can add or remove delegates at his or her discretion.
   (8.2)
8. The DPL cannot make someone's status as a delegate dependent on the outcome of a particular decision that they make within their authority as a delegate. That is, the DPL cannot say, e.g., "If you drop non-free from ftp-master.d.o, you no longer get to be a package archive administrator."^[2]
   (8.2)
9. The DPL cannot override the decision of a delegate once the delegate has made it.
   (8.2)
10. The Developers can override the decision of a delegate via a General Resolution with a simple majority.
    (4.1.3)

Let me know if you feel this is an inaccurate characterization of the Constitution; I've done my best, but I'm not infallible. Also, I'd like to hear your thoughts on whether you think delegation is a tool that I should use more. I appreciate your comments. ^[1] One might argue that the prohibition on rescinding delegation of a particular decision is tied the individual(s) to whom it is given, rather than the decision in question. This is important if the person or people to whom the decision is delegated prove unable to make it. This is another variant on the old "what if Linus (Torvalds) gets hit by a bus?" problem. One developer has told me that my interpretation poses a different threat, however: "It looks like you're going to decide this one issue in a way I don't like, so I'll take it away and give the decision to someone who will decide it the way I want to." Why a Leader would do this, or how he or she could expect to get away with it, is not clear to me, but this scenario is not impossible. If this ever proves to be a non-hypothetical problem, I would ask for the Project Secretary's interpretation of the Constitution. ^[2] In practice this is hard to enforce perfectly, especially if the DPL keeps his or her reasons for dismissing a delegate to him- or herself. Personally, I interpret this to mean that if the DPL attempts to sway or threaten a delegate with the loss of their position if he or she does not do the DPL's bidding on a particular issue, that the delegate should bring the DPL's misconduct to the attention of the developers. Originally published 2005-11-15. Updated 2005-11-15 to fix instances of awkward (and in one case, backwards) wording.

I have published the slides to my DebConf 5 presentation, WTFM: Write the Fine Manual. An example manpage (PostScript output) and script for finding executables on your system that are missing manpages are also available.

A few days ago, I issued my third report as Debian Project Leader. I do make corrections to my reports as feedback comes in (for a week or so), so if you read anything that made you blink your eyes a few times on the day I first posted it, you might find it worth a second look.

make World is what you type when you want to do a full build of the X Window System sample implementation. With significant embroidery, it's also the heart of the xfree86 and xorg-x11 source packages' debian/rules files. Today, I got a successful package build of the xorg-x11 SVN trunk. One needs new versions of the render-dev and libxrender-dev packages to do so; the former has been accepted into unstable, and the latter is currently in queue/NEW. There's a bit of housecleaning and QA still to do before uploading to experimental, but the worst of the hurdles are cleared, and that's a mighty good feeling. Hopefully David Nusinow returns from his "forced vacation" soon. :-) There are many things to catch up on on the DPL front (and a few others), and I owe everybody an explanation of why I've been so quiet lately. Strapping on my boots to give xorg-x11 a kick in the ass has been part of it, arena-style bureaucratic combat with the Brazilian Consulate General's office in Chicago was another, and my wife's recent re-hospitalization was the most worrisome. I lost out on my trip to FISL 6.0 in Brazil, but kept my wife, which is, I think, the preferable outcome if I could only have one of the two. (Those of you who are members of SPI can also check out a report from me on recent donations and bank activity.) It's satisfying to make progress on a couple of fronts even when you're fightning an n-front war — it beats the hell out of losing ground. Yup, today was a good day to make World.

It was inevitable, really... With the merger of the uClinux project's code into the official Linux kernel as of version 2.6, and the against-all-odds development of the EMILE boot loader, one might say this day was destined to come (I'd have more details from a mailing list, but unfortunately its archives appear to be broken). Laurent Vivier, I don't care what the Vancouver Prospectus has to say about your work — you rock. :-)

I'm probably the only person who ever thinks like this, but what the heck. I recently found myself thinking (itself a noteworthy occurrence)...I've started a what turns out to be a long-running process at a shell prompt and I don't want to visually monitor it. It didn't occur to me that it would take a long time when I started it, and it would be nice to have audio notification of its completion. The problem is, it's already running. Of course if you knew it was going to take a long time when you started, you could have done something like this: long-running-process && xmms $HOME/music/song.ogg. Let's say you didn't exhibit that much foresight. Traditional Unix process management primitives exposed via the shell come to the rescue.

$ long-running-process

Damn, this is taking a while... <CTRL-Z>

[1]+  Stopped                 long-running-process
$ bg
[1]+ long-running-process &
$ wait %1 && xmms $HOME/music/song.ogg

Voilà; I can go back to occupying myself, and when the music starts up, I know my job is done — and I didn't have to kill it and start it over. Once in a while, that's an important consideration. By the way, if you try to wait on a stopped job, you're helpfully told how lame you are:

-bash: warning: wait_for_job: job 1 is stopped

...and the music starts to play even though your job isn't finished. So don't forget to background it first. :) Futhermore, this usage of wait appears to be standard. In Debian, both bash and ash (a.k.a. dash) support both process IDs and job IDs as operands to wait. zsh probably supports identifying the job by its mother's maiden name as well, but I haven't tried that.

I have issued my second report as Debian Project Leader.

Via FindLaw: Defense lawyers sought leniency for Pfc. Lynndie England at a hearing Tuesday to determine her punishment in the Abu Ghraib prison abuse scandal, with a psychologist testifying that the reservist was oxygen-deprived at birth, speech impaired and had trouble learning to read. The most persuasive indication of her mental incapacity, the defense expert continued, was that England volunteered for the U.S. Army in 2001, after George W. Bush assumed the Presidency.

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions.

• Why even have a trademark? Let's understand what protections the law affords and determine which, if any, are applicable to our endeavors. In the U.S., trademarks are managed by the federal government (rather than the states), and regulated by Title 15, Chapter 22 of the United States Code. International treaties result in trademark law being roughly similar across most jurisdictions in the developed nations, but there could exist important differences that we should learn about.
• What level of Debian involvement should be necessary for an "outside" organization to use our mark without a fuss from us? Should there be any situations where people essentially have an automatic trademark license, or should we use trademark law as an instrument to encourage (or compel) anyone trading in our name to contact us? We need to consider small-scale garage-based redistributors who simply move physical copies of our official ISO images as well as commercial derivative distributions.
• Is it feasible to apply the copyleft concept to trademarks? That is, is there some way we can turn the restrictive aspects of trademark law into a kind of compact that upholds the freedoms of a sharing community, while penalizing the activities of those who would prey upon that community?

Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

Thanks to the hard work of Debian's Release Management, Archive Administration, and Security teams, as well as Debian's developers generally, Sarge has now been frozen (don't let the modest title fool you). ;-)

Courtesy of FindLaw Legal News: WASHINGTON-President George W. Bush said Wednesday that Harriet Miers' religious beliefs figured into her nomination to the Supreme Court as a top-ranking Democrat warned against any "wink and a nod" campaign for confirmation. "People are interested to know why I picked Harriet Miers," Bush told reporters at the White House. "They want to know Harriet Miers' background. They want to know as much as they possibly can before they form opinions. And part of Harriet Miers' life is her religion." Courtesy of the United States Constitution, Article VI: ...all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States. Oh, well, just so long as it's a criterion, not a test. I mean, it's only essential, not a qualification or something, right?

Since I got back from the Oldenburg Linux Developers' conference, I've had my attention on our security infrastructure. Despite only being there for one and a half days thanks to a badly delayed trans-Atlantic flight, I found the conversations and collaborative spirit heartening. The bad news is that what I had planned for a writeup got rendered obsolete soon after I returned to the United States. Things have been changing rapidly, but mostly for the better. We've got three machines in the DNS rotation for security.debian.org now, which is superior to the one we had before (you can use the command dig security.debian.org to inspect the DNS record). My thanks go to our security and system administration teams for recovering from the recent overload problem provoked by an xfree86 package security update. Being somewhat familiar with that package, I can understand how its large size combined with Debian's ever-growing userbase starved the security host of bandwidth. Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of insight into what a challenge one particular package is — the thing sucks up at least half of his time, dwarfing all other stable security update efforts. You've probably guessed that this package is the Linux kernel. Due in part to its success, and in part due to OS kernels being inherently attractive exploitation targets, the Linux kernel is getting a significant amount of scrutiny from a security perspective. Taking Red Hat Enterprise Linux as an example, we can see two advisories in the past two weeks: one on 28 September and one on 5 October. The one on 28 September addressed eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's one week later — addressed fourteen (14) vulnerabilities, of which eight (8) were distinct from the previous advisory. (There was some overlap because the earlier advisory was for Red Hat's Linux 2.4.x kernel series, and the latter was for the 2.6.x series.) Those Debian developers who have ever handled a security vulnerability in one of their own packages can likely imagine the labor burden this is. Then reflect that Debian ships and supports a lot more Linux kernel trees than Red Hat does — this only magnifies the problem. The good news is that a team of developers focused on stable kernel security updates has been established. One of its members said to me today that he has seen a "very positive increase in kernel-related security activity". It is too soon to declare this problem resolved, but I perceive no lack of talent or dedication on the part of our developers. I am there to assist them in resolving the organizational and workflow issues so that our users can see the fruits of their energy directly. Similarly, I'm interested to see how the security.debian.org round-robin arrangement holds up after a reasonable period of real-world loads, particularly since I expect kernel package updates to sock the machines about as badly as an X Window System update. These issues are not over and done with, so an announcement declaring these problems vanquished would be premature. At the same time, the developers and users at large need to know whether or not people have their attention on them. I am wary of leaders or managers who declare issues resolved too soon, or proclaim optimism that later turns out to be unfounded, and have sought to avoid this vice. I apologize if I have tacked too far in the opposite direction. I perceive progress in this area. Let me know what you think, what you need to see, and by what metrics you measure progress and accomplishment on the security front. You can reach me at leader@debian.org (the address is already blitzed with so much spam there seems little sense in obfuscating it). (After getting some feedback on this entry, it's my intention to post it with any applicable revisions to the debian-devel-announce mailing list; please take this opportunity to "patch" this "beta", if you're so inclined.)

Planet Debian readers, please accept my apologies for the re-post of the old entries on Lynndie England and Lester Crawford. Lars Wirzenius and Mark Brown helped me figure out that having spaces in my directory names (for categorizing entries) was a bad idea because PyBlosxom doesn't have sense enough to perform proper escaping of the contents of link elements in the RSS it generates. No doubt this confuses aggregators the one used by the Planet, which seems to more or less muddle through. Anyway, I changed the spaces to underscores, and while the timestamps of the files within the directory didn't change, that was enough to make all the entries contained in it look new again. A quick glance at PyBlosxom's source leads me to believe it's pretty crude about escaping and substitution issues generally. Anyone wanna go over it with a fine-toothed comb and make it better? ;-) (Then too, I could upgrade to PyBlosxom 1.3, which claims to fix bugs, but the version available in Sid is still 1.2.1.)

Courtesy of the Wikipedia's Current Events page: Lester Crawford, U.S. Food and Drug Administration Commissioner resigns, citing old age. Critics accuse Crawford of incompetence regarding Vioxx, cloned beef, approval of malfunctioning heart devices, and alleged corruption. He served two months in office.

Philipp Kern: to put it simply, you're right. I appreciate your frankness, and yours is exactly the kind of feedback I need to do a better job. The primary reason for transitioning DPL reportage from monthly reports to blog entries is because I have found that most things in Debian that require my attention do not unfold neatly on a month-to-month basis. The ongoing attention to stable security updates, for example, began in June, carried forward through DebConf, and brings me to Oldenburg this weekend. Activity tends to be "bursty" instead of steady, which makes sense given that most of us don't have salaried jobs we can dedicate to Debian (I don't, certainly — my day job just has some overlap with my avocation). The emphasis I placed on visibility, demystification of Debian processes, and reform of the ones that don't work well remain my focus. To that end, it seems logical to me that it would only compound a failure to issue monthly reports by withholding information until I do issue one again. I'm trying to keep people informed, and if the information I've been sharing via my blog entries about DPL matters is of little value, then I need to know that — please tell me. planet.debian.org, by virtue of its .debian.org address, is an official project resource, which is why I think it's a suitable forum to use for communication with Debian's developers and users. Similarly, I am acting in my elected position when I post to any other Debian mailing list, even though subscription to other lists by developers is not required, and I act in that position when I speak with the press. I expect to be held to account for my statements in those forums, and I suspect you'd agree that I couldn't avoid responsibility for them by claiming that I didn't make them to debian-devel-announce. Whether I have good reasons for falling behind on the monthly reports or not, and whether or not I still think now they are the best way to maintain visibility is beside the point. I fully expect, if I run for election against next year, for my rivals to make much of the failure. My primary concern, however, remains serving the membership of our organization, and the users of our distribution, as best I can. To that end, I have a question for you and others: should I re-post blog entries about leadership matters to debian-devel-announce, or is that needlessly duplicative? Along the same lines, is it desirable that I stop (or reduce) blogging in favor of emails to debian-devel-announce? Let me know what you think; post to the Planet, and/or mail me at leader@debian.org.

Short version first: those in Oldenburg who are expecting me to arrive at the Bremen airport on Friday afternoon, don't. Expect me on Saturday at 11:10 instead, assuming there are no further setbacks. I got to the Indy airport today in time for my flight, except my flight was going nowhere fast. "No problem," I thought to myself. "I have nearly a three-hour layover in Newark. They can dicker with this flight for quite some time, or I can get switched over to the flight on the commuter jet that Continental also has going to Newark this evening." Silly me. My flight has a "wing indicator light" problem — that's what the gate agents called it, shrewdly deducing that a pilot otherwise has no way of determining whether the lifting surfaces are still attached to the aircraft — that amazingly takes hours to resolve, and the other flight? Well, Continental's headquarters are in Houston, and apparently some of their employees startlingly decided to evacuate their families out of the expected path of Hurricane Rita instead of showing up to work in Indianapolis to be the flight crew. Or something like that. So instead of getting to switch over to the flight that would get me to Newark safely in time to catch my connecting flight to Paris, the airline shunts all those passengers onto my flight. So we take off about 3 hours and five minutes late, and when I land in Newark, there's nothing left of my flight to Paris but wing tip vortices spiraling out over the hypodermic-syringe-strewn New Jersey coast. Apparently airports both in the U.S. and Europe have a problem with flights leaving or arriving in the middle of the night, so the soonest I can leave for Europe is now 1845 on Friday. This means I'll miss nearly a full day of the conference, which I was only going to be at for 2.5 days anyway. Joy. Oh, and they also close down baggage claim at 11pm (or five minutes before you land, whichever comes first), so my checked bag which couldn't make the same flight I couldn't is now being held hostage somewhere in the bowels of Newark Airport while I sleep at the Howard Johnson's in a room that one dare not view in ultraviolet light. Well, technically, this hotel is joint venture with Holiday Inn, an enterprise which no doubt serves the sole purpose of frustrating class-action liability suits by people who contract scabies in the course of their stay. I don't even know if my beloved dismantled Quadra is in better accommodations, or if my machine, tortoise.deadbeast.net, stuffed into a suitcase and crudely protected with towels and masking tape, has been obliterated with patriotic fervor by the TSA, swinging their hammers to pulverize it. I guess I could be in worse places, like Galveston. Any DDs in New York wanna give me a wake-up call in the morning and meet for lunch? (I'm at +1 973 589 1000 x217.) If not, I was thinking I might try to go see the Statue of Liberty in the late morning. I've been in the NYC area twice before but never went to see it. Air travel sucks. Maybe this is the real reason, unadmitted to myself until now, that Contact resonates with me. I can almost forgive Robert Zemeckis for that brown smear he did with Tom Hanks three years before. Then I remember that other brown smear he did with Tom Hanks three years later. Okay, I won't blame Hurricane Rita or even Continental Airlines. I'll blame Robert Zemeckis instead. :-P I'm okay to go... I'm okay to go...

On Friday afternoon I'll be arriving in Oldenburg, Germany, for the eleventh annual Linux developers' conference. Historically, this conference has had a strong focus on non-x86 ports of the Linux kernel, boot loader development, the GNU toolchain, and so forth. At long last, it looks like this may be my opportunity to get my Macintosh Quadra 840AV out of mothballs and back into commission, thanks to Wouter Verhelst. I should be able to fit it into my luggage if I don't bring many clothes... :-) This year, however, in addition to that, a couple of mini-conferences are being piggybacked onto the Oldenburg meeting. These include the GNU Classpath and Debian Java DevJam and the Debian Security Summit. The Java programming language is a divisive issue in the Free Software community, and has a degree of controversy that sets it apart from the usual language wars. The dominant factor in this controversy stems from what Richard Stallman refers to as the Java trap; with the specifications controlled, and the reference implementation kept unavailable on DFSG-free terms by, an industry consortium dominated by large corporations, a Free Software hacker might fear that using Java will consign them to either having to compromise their principles by using non-free class libraries (for example), or being doomed to chase the taillights of standards that could conceivably be tailored to disadvantage competitors. (Java is not alone in this respect; many people fear that Microsoft's .NET, despite being openly standardized through ISO/IEC, will in actuality be completely controlled by Microsoft.) Despite this peril, Java is attractive to GNU/Linux-using organizations. The Free Standards Group, developers of the Linux Standard Base, has received inquiries about a Free Java standard and implementation from organizations already committed to GNU/Linux. In my job, I've encountered an interest in Java from several customers and prospects. Intriguingly, these institutions are, by and large, very much aware of the Java Trap. They like the language, and are not strong advocates of Free Software, but they too are worried about vendor lock-in. They've seen the success of community-driven development as GNU/Linux moves from strength to strength, claiming territory formerly held by Microsoft and proprietary versions of Unix. Even if I can't persuade a customer to adopt a Free Java stack, I can exhort them to only code against Java standards that have seen a free implementation. That way, their development bets are hedged against any "madman theory" of the controlling vendor. Furthermore, this way they only code to standards that are seeing independent implementations, and they leave their engineers free to switch between varieties of development kit. Engineers like flexibility because it enables them to work more efficiently; sales people, marketing personnel, and strategists like efficient engineers because they make a firm more nimble. That's where the GNU Classpath and Debian Java DevJam comes in. Free Software Java enthusiasts want to see their implementations fully mature, and are working hard to make it so. The Free Software community has the opportunity to make its Java implementation not just an available alternative, but a compelling alternative to the proprietary ones on technical as well as licensing grounds. The recent release of GNU Classpath 0.18 shows just how vigorously this opportunity is being seized. Having mature software is only half the battle, however; that software has to be coherently put together and easy for the user and developer to manipulate. For many of these folks, it's not enough just to have good, Free Java virtual machines (like Kaffe and SableVM), class libraries (GNU Classpath), compilers and interpreters (gcj and gij, respectively, from the GNU Compiler Collection), and application servers (Jakarta Tomcat, JBoss, and JOnAS, among others). They also want these technologies to be mutually integrated and easy to install and use. Good software and good packaging complement each other to drive adoption of the technology, and that's what the DevJam is all about. I'm glad to see that representatives of Debian's Java packaging team will be joining not just upstream authors, but their counterparts at Fedora, Ubuntu, and Gentoo in furtherance of this goal. I've approved a budget of EUR 2000, which Petter Reinholdtsen will administrate, to support the expenses of Debian's participation in the DevJam. We've received 1500 USD in sponsorship of this event from a corporate sponsor that chooses to remain anonymous. The other mini-conference I'll be attending is the Debian Security Summit. We're bringing together the heads of our Stable Security and Testing Security teams — the two Joeys, Joey Schulze and Joey Hess, as well as a bevy of other security-minded people, with the goal of revitalizing and streamlining our security processes. Several members of the Stable Security Team have gone dormant over the past several months (or longer), leaving an increasingly small number people to handle, as of Sarge's release, not one but two stable releases. This is because we do not terminate security support for our previous stable release (in this case, Woody), until some time has passed. We've had other challenges on the security front. We had what amounted to a security support hiatus for about three weeks in June, which caused much consternation. More recently, klecker.debian.org, which provides the security.debian.org has suffered some occasional availability problems, and it hasn't always been clear what's caused them. It's my understanding that we have new hardware in place that can serve in a backup, supplemental, or failover capacity. The general feeling at DebConf 5 was that our security apparatus was in need of attention to make sure it keep pace with the demands being placed on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and others over the past several weeks, and I look forward to a productive few days.